…296]

Detect array u64 integer-reply commands (ARLEN/ARCOUNT/ARNEXT/ARSCAN/ARGREP) in the CLI and request { integerReply: 'bigint' }; the raw/utf-8/text output formatters stringify BigInt so the result isn't rounded and doesn't break JSON serialization.

References: #RI-8296

…set [RI-8296]

Workbench executor opts array u64 integer-reply commands into { integerReply: 'bigint' } and its UTF8/ASCII reply transformers stringify BigInt — same as the CLI. Extract ARRAY_U64_INTEGER_REPLY_COMMANDS into browser-tool-commands.ts as one source of truth for both.

References: #RI-8296

…8296]

With the per-command bigint engine, the search endpoint returns the exact u64 index, so the >2^53 round-trip (de-scoped on #6090) is proven again.

References: #RI-8296

…8296]

main's read-endpoint precision tests use values >= 2^63, which Redis sends as RESP bulk strings (exact without the engine). Add round-trip cases at 2^53+1 — a RESP integer that a JS number rounds — so ARLEN and ARSCAN actually exercise the per-command bigint path. ARCOUNT/ARNEXT can't reach the zone (count/cursor never approach 2^53).

References: #RI-8296

Raw-socket probe asserting the actual RESP type byte: a length in (2^53, 2^63) comes back as a RESP integer (':') exact on the wire, and a length >= 2^63 as a bulk string ('$'). Pins the boundary the per-command bigint engine relies on, so a future Redis encoding change trips a test instead of invalidating a comment. Gated to standalone 8.8.

References: #RI-8296

…-8296]

Use requirements('rte.type<>CLUSTER') instead of an in-test this.skip(); the imperative form tripped the strict check tsconfig (TS2683 'this' implicitly any).

References: #RI-8296

test.Dockerfile copied patches/ after yarn install, so patch-package found nothing and the ioredis bigint parser never applied — every (2^53, 2^63) array reply rounded in CI. Copy patches/ before install, mirroring the root Dockerfile.

Also fix the RESP wire test's cluster gate: conditionalIgnore has no '<>' operator (always skips), so use the supported '!rte.type=CLUSTER'.

References: #RI-8296

…RI-8296]

The RAW, ASCII and UTF8 reply formatters stringified bigint integer replies, so the CLI and Workbench rendered u64 array indexes as quoted strings instead of (integer) N. Tag them as { type: 'integer', value } and render the tag in cliTextFormatter, matching redis-cli. Add ARINSERT and ARRING to the u64 integer-reply opt-in.

AROP AND/OR/XOR return a u64 bitwise result that can exceed 2^53; without
the per-command bigint opt-in the CLI and Workbench rounded it, breaking
the exact-precision path the aggregate response documents.

References: #RI-8296

…t [RI-8296]

The added bigint test cases reused the untyped `let strategy`, so each new
`strategy.format` call raised TS7005 above the recorded baseline (masked
locally by a stale incremental tsbuildinfo; CI compiles fresh and fails).
Annotate the variable in each spec and refresh the API baseline downward.

References: #RI-8296

…-8296]

ArrayService.aggregate sent AROP without the bigint opt-in, so AND/OR/XOR
(and the MATCH/USED counts) above 2^53 rounded before toIndexString saw
them — the Array-tab API returned a rounded value while only Workbench was
exact. Request AROP with { integerReply: 'bigint' } so every operation
stays exact (SUM/MIN/MAX are bulk strings, unaffected), drop the
Workbench-only caveat from the response contract, and add a real-server
gap-zone OR test alongside the SUM one.

References: #RI-8296

ARINFO returns array metadata (length/count/cursor) that for a sparse
array can exceed 2^53, but CLI/Workbench left integerReply unset for it,
so ioredis rounded the nested integers. Add it to the opt-in set so the
metadata renders exact.

References: #RI-8296